Devin/feature/add dfgm interface and handler#3
Conversation
|
Good start! Have you thought much about how you want to manage DFGM data long term? In the Architecture Document the topic should be bulk data management and upload/download. We might need to think about circular buffers so the files don't grow without bound, and possibly a time-stamp Table of Contents so you don't always have to read the entire file. I think the DFGM probably has too much data to download through the command interface (I thought I saw that in dispatch). |
|
Thanks for the feedback! I haven't thought a bunch about particulars relating to the DFGM in the spirit of trying to stick true to the 'tall and thin' implementation approach, where I implement this as the most lightweight implementation while still be useful for a subsystem interface and handler architectural components. This being said these things are in the back of my mind, I just figured I could deep dive and implement them later once we have more of a full skeleton of our entire architecture / software stack. Today I am doing to setup a simple command dispatcher, which will be responsible for sending commands to their associated subsystem handler based on the commands 'destination id'. With this in mind, do you think I am good to merge this PR and continue on our tall and thin journey? |
…evers implementing it to define unique logic for handling data read from the fifo.
2 participants
DFGM stuff moved into separate directory. Now There is an abstract dfgm interface that can be modifed later to talk to UART or TCP, and the dfgm handler doesnt care which. (Useful for either using simulated subsystem or actual hardware).
As well setup DFGM handler to write DFGM packet data as its received if a dfgm listen flag is set true. This will bring us one step closer to a tall and thin demo of the entire mission software stack.